server/influxdb.ts (3)

147-151: Consider resetting module state in closeInfluxDB.

When closing the InfluxDB connection, queryApi and enabled are not reset. If the module is reinitialized after close, stale state could cause issues. Additionally, closeInfluxDB should handle errors gracefully.

♻️ Proposed improvement

 export async function closeInfluxDB(): Promise<void> {
   if (writeApi) {
-    await writeApi.close();
+    try {
+      await writeApi.close();
+    } finally {
+      writeApi = null;
+      queryApi = null;
+      enabled = false;
+    }
   }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/influxdb.ts` around lines 147 - 151, In closeInfluxDB, after awaiting
writeApi.close(), also null out or reset module-level state variables queryApi
and writeApi and set enabled to false so the module can be safely reinitialized;
wrap the close logic in a try/catch to log or handle errors (without throwing)
so cleanup doesn't crash the process and ensure the catch clears state as well
(referencing closeInfluxDB, writeApi, queryApi, and enabled).

---

35-43: Consider extracting the metrics type to src/types.ts.

The inline type definition for the metrics parameter duplicates the structure already partially defined in src/types.ts (which has CpuUsage and SystemMetrics). Extracting a shared type would improve maintainability.

Based on the relevant code snippet from src/types.ts, the CpuUsage interface already matches the cpuUsage array element type here.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/influxdb.ts` around lines 35 - 43, The writeMetrics function uses an
inline metrics type that duplicates existing types; instead import CpuUsage and
SystemMetrics (or a combined SystemMetrics-like interface) from src/types.ts and
replace the inline parameter type in writeMetrics with the shared type (e.g.,
metrics: SystemMetrics or a new alias that combines CpuUsage array and the
memory/load/process fields). Update the function signature in writeMetrics and
add the appropriate import at the top so the function refers to the centralized
types instead of the inline definition.

---

98-101: Non-blocking flush swallows errors silently.

The .catch() logs the error message but doesn't propagate the failure. While this prevents blocking the request, consider adding a counter or metric for write failures to aid debugging in production.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/influxdb.ts` around lines 98 - 101, The current non-blocking flush
(writeApi.flush().catch(...)) only logs err.message and swallows failures;
update the catch handler for writeApi.flush() to (1) log the full error (err)
with context, and (2) increment or record a write-failure metric/counter (e.g.,
call metrics.influxWriteFailures.inc() or influxWriteFailures.increment()) so
failures are observable in production; ensure the metric is imported/initialized
(or created alongside existing metrics) and do not rethrow to keep flush
non-blocking.

server/index.ts (1)

22-23: Consider logging the initialization result.

initInfluxDB() returns a boolean indicating success, but the return value is ignored. While the function logs its own status, capturing and using the result could be useful for conditional startup behavior or diagnostics.

♻️ Suggested improvement

 // Initialize InfluxDB timeseries storage
-initInfluxDB(debug);
+const influxInitialized = initInfluxDB(debug);
+if (DEBUG) {
+  debug("InfluxDB initialization:", influxInitialized ? "success" : "skipped/failed");
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/index.ts` around lines 22 - 23, The call to initInfluxDB(debug)
ignores its boolean return; capture its result (e.g., const influxInitialized =
initInfluxDB(debug)) and log or act on it so startup can respond to failure—use
the returned value to emit a clear processLogger/info or error message and
optionally adjust startup flow (e.g., exit or continue degraded) based on
influxInitialized; reference the initInfluxDB symbol where the call is made and
update nearby startup logic to handle the boolean result.